MITRE publication ‘11 Strategies for a World-Class SOC Centre’. Strategy #3 ‘Align your SOC structure to your company's needs’. Part 2

Ruslan Rakhmetov, Security Vision

In the previous article we started to consider strategy #3 ‘Build SOC structure according to the company's needs’, in which the authors of the publication consider different variants of SOC structures, SOC organisational models, SOC premises, as well as discuss the feasibility of outsourcing SOC functions and introducing a 24-hour duty shift. This article continues this review.

4. Selection of SOC functions and services

Formally, in order to be called a SOC-centre, it is required to satisfy the following conditions: to receive incident reports from customers, to help customers respond to incidents, to give them feedback on incidents. But this scope of tasks is only the minimum necessary, so managers should decide what other services the SOC can offer.

The SOC's strategic priority is to support the customer in the cyber risk management process, so the services offered should help achieve this goal by carefully managing the expectations of the customer's executives and employees, earning trust and credibility by handling each incident thoroughly and expertly, avoiding spreading resources across multiple tasks simultaneously, taking on additional responsibilities and roles only when sufficient resources become available, and ensuring that the SOC is able to fulfil its role in the cyber risk management process.

Before deciding on the scope of services to be provided by the SOC centre, it should be analysed whether the SOC's mission matches the customer's expectations, whether the SOC should be independently involved in monitoring and response or only manage the activities of subsidiary SOCs, the position of the SOC in the company hierarchy and the resulting focus of activities (e.g. providing situational awareness or rapid implementation of countermeasures in the event of a cyber attack), what capabilities can be provided externally (e.g. by the parent SOC or by outsourcers for an anaerobic attack), and what capabilities can be provided externally. In general, prioritising the quality of services provided over the quantity of services should be the guiding principle.

When deciding on the scope of the SOC centre services to be provided, the authors of the publication recommend that the following points be considered:

1. Real-time monitoring and categorisation

This function implies that the SOC should receive a stream of alerts that are triaged (categorised) by analysts. New, small or virtual SOCs may operate in a purely reactive mode (reacting when the consequences of an incident are detected), hence triage is not useful in this case.

2. Real-time monitoring and categorisation, analysis and investigation of incidents

This function is key for almost all SOC centres, with very large coordinating SOCs not handling the flow of IS events, but handling reports and requests from other SOCs.

3. VPO analysis, forensic artefact analysis

These functions are quite difficult to implement in most SOCs, because in order to effectively use the labour of highly skilled reverse engineers and computer forensics specialists, it is necessary to provide them with a steady stream of incidents requiring analysis. This function may be a prime candidate for outsourcing even in large and established SOCs.

4. Incident response with travelling to the customer site

This function is determined by the geographical spread of the customer and depends on whether an internal distributed SOC model is used. In addition, in the event of a major incident, it may be more appropriate to engage an MSS provider to perform a remote site visit in-house.

5. Setting up sensors and analytics

Where the SOC operates a fleet of monitoring equipment and PPE (e.g. EDR, SIEM, UEBA, SOAR class systems), their configuration should be a continuously maintained internal activity that takes into account feedback from analysts; hence, this function is considered essential for SOCs performing monitoring functions. It is important to note that sensor and rule tuning is an ongoing process necessary for the correct operation of the SOC technology fleet, and therefore should be performed as part of the SOC's operational activities.

6. Vulnerability Analysis, Attack Simulation and Auditing

For some customers, performing these tasks may seem like a natural function of the SOC centre, allowing the SOC to provide greater situational awareness and increasing the credibility and visibility of the SOC amongst the company's employees. Some customers, on the contrary, may assign these functions to departments other than the SOC due to the high labour costs of their implementation, depending on the number of SOC employees and the need to obtain an independent view of the status of these functions from the SOC.

7. Vulnerability remediation

Installing updates and handling vulnerabilities in other ways as the SOC grows is usually outsourced to IT or another dedicated unit.

8. Vulnerability assessment and vulnerability scanning

These tasks may be perceived as supporting IT functions rather than cybersecurity functions, so their inclusion in SOC functionality should be a case-by-case and executive decision. Regardless of the inclusion of these tasks in the SOC functionality, the results of scans (scan reports, network diagrams and charts) should be available to the SOC as they are relevant for incident analysis.

9. Develop and manage network defence functions

Network defence systems (IDSs, IPSs) and firewalls may be part of the functionality of many devices and system installations. As a result, the management of network defences may be transferred to IT, with the SOC remaining the recipient of IS events from network defences, as well as being involved in device and signature configuration.

As the maturity of the SOC increases, the number of capabilities expands, which also depend on each other to some extent:

1. Collecting and processing cyber threat data, configuring sensors and analytics, with growth to proactively searching for cyber threats and creating customised signatures

Continuous work with various sources of cyber threat data teaches analysts to be more selective in their application, contribute to the development of new defence techniques and identify attackers before they penetrate the infrastructure (‘left of hack’). Understanding the TTPs of attackers and the company's infrastructure, as well as the analytical skills acquired, organically contribute to the creation of customised signatures and techniques for detecting cyber threats.

2. incident analysis, VPO analysis, creation of customised signatures and analytics, growing to the creation and dissemination of proprietary cyber threat data

Over time, analysts' experience with individual incidents should grow into a higher-level understanding of attacker behaviour, which helps analysts develop their own observations and conclusions that can be shared with peers, customers, other SOCs to increase their situational awareness.

3. incident analysis and forensic artefact analysis, with an increase to analysis of VPOs and malware-implants deployed

As the number of cyber incidents increases, the effectiveness, consistency of the SOC in handling them also increases synchronously. The need for root cause analysis of incidents leads SOC employees to the fact that, on the one hand, as the number and complexity of incidents grows, the need for an established process of processing traffic dumps and artefacts using specialised technologies and competencies increases, and on the other hand, the increasing number of detected VPOs leads to the need to understand the real danger of a particular VPO sample and assess whether the attack was targeted or massive. The SOC can further come to proactively identify threats in network traffic with regular static and/or dynamic analyses of extracted files.

4. Customisation and installation of SOC toolkits, with growth to the development of in-house toolkits

As the number and complexity of tasks increases, the SOC will likely begin to feel the limitations and functionality shortcomings of existing tools, leading its team to develop its own tools. This process may start with integrating the various Open Source and commercial solutions already available and further evolve into building and providing customers with off-the-shelf, self-developed solutions.

5. Should I build my own SOC?

Creating your own SOC cannot and should not be a prerequisite for monitoring and responding to cyber incidents - the choice of how to implement and receive these processes depends on various factors (most often the size of the company, its dependence on information infrastructure and financial capabilities). Some companies may opt for an outsourcing model, while others may prefer an in-house implementation. It is also possible to choose a hybrid scheme, where some functions are implemented in-house (e.g. basic monitoring and response), and outsourced for specific tasks (e.g. penetration testing, VPO analysis).

5.1 A company that is likely to be suited for internal, in-house implementation of SOC functions is likely to be characterised by the following features:

- Has a dedicated IT function and recognises the key importance of IT to the business;

- Has thousands of devices (IT, OT, network devices) and has thousands of accounts running on the infrastructure;

- Invests in cyber security, manages risk, appoints a dedicated IS officer, builds processes for vulnerability management, compliance, engineering services;

- Has needs that cannot be covered by MSS providers' offers, such as: specific monitoring, response, protection requirements that cannot be met by standard offers and SLAs; requirements for the use of specific tools; restrictions on access to infrastructure by third-party employees; limited access to assets from the Internet; needs for a high level of involvement of SOC employees in the company's business processes;

- Has the ability and willingness to allocate resources to find and retain dedicated SOC employees, to invest in SOC technology, and views investment in increasing cybersecurity maturity as a sound investment.

5.2 A company that is likely to be suited to an outsourced model of SOC centre functions is likely to be characterised by the following features:

- Does not have the resource endowment and competences in IT;

- Has less than a thousand devices (IT, OT, network devices), with less than a thousand unique accounts running on the infrastructure at any one time;

- Does not invest in cybersecurity, build a risk management process, or provide situational awareness within the company;

- Does not have the budget to dedicate more than two employees to cybersecurity;

- Does not have the ability, need or desire for monitoring, analytics, scanning tools, including cloud and on-prem technologies;

- Aware that all IS needs will be covered by the MSS provider or, in the case of belonging to a holding or other large structure - by the parent organisation's SOC;

- Appreciates the ability of a third party organisation to respond to incidents involving company assets without the risks of errors or high integration costs;

- Does not require continuous involvement of the IS team in the company's operations;

- Expects prompt receipt of monitoring and response services, not interested in developing the SOC function within the company.

5.3 Success factors in outsourcing

The success of outsourcing of SOC centre functions depends on the contractual and business relations between the customer and the outsourcing company, business expectations from outsourcing services, relations between the company's employees and outsourced employees, as well as on the general business culture and sense of responsibility for cyber security in the customer company. It should not be forgotten that the ultimate responsibility for cybersecurity and consequences of cyberattacks lies with the client company's executives, not with outsourcers. It should also be taken into account that both outsourcers and outsourced IS functions will require constant involvement from the client company, as they will not be able to work on their own. Despite these limitations, there are a number of arguments in favour of choosing the outsourcing model:

- Shortage of skilled IS specialists;

- The company cannot afford to pay market salaries to SOC employees in the relevant geographic region;

- The company is not large enough to build its own SOC;

- Inability to fill needed staff positions due to infrequent demand (e.g., VPO analysis) or requests (24/7, night shifts);

- Anticipating spikes in staffing needs, e.g., major incidents;

- The need to ramp up SOC staffing quickly, without waiting for natural, gradual growth over time;

- The simultaneous departure of a large number of SOC employees and the need for rapid temporary closure of the resulting gaps.

5.4 Expansion of SOC staff with the help of outsourcers

In this option the SOC is built in-house in the customer company, the SOC is managed by the customer's employees, and all or part of the SOC employees are outsourcers, i.e. are on the staff of the contracting company. This option can be used when a company is able to maintain its own SOC, but needs additional staffing or wants to reduce costs by using a contractor. It should be taken into account that contractors themselves may have difficulties with staffing and qualification of their specialists, and the customer will need to control the quality of work and qualification of the outsourcers provided, as well as to solve the problem of full involvement of outsourcers in the work (the customer company can support the culture of involvement in the work of all, including outsourcers, for example, by organising joint team-building and other events, career promotion of the most active outsourcers and control over their work).

5.5 The choice of SOC functions to be outsourced

For small and not quite mature SOCs, both centralised and distributed, it is logical to outsource some of their functions, given the limited financial and human resources to cover all the needs of the SOC. Popular functions that are outsourced by SOC centres are:

- Alert triage outside of standard business hours

This function is typically assigned to L1 level SOCs that operate 24/7. When outsourcing this function, consider that the company will have to give the outsourcer access to some of its tools, as well as define in advance what actions will be performed as part of the alert triage. It should also be taken into account that often L1 level operators ‘grow’ within the SOC to more responsible positions, and if there is no L1 level, it will be necessary to recruit already trained specialists from outside.

- VPO and drive forensics analysis

In case the SOC requires these competences only occasionally and needs more detailed analyses that cannot be performed by automated means (‘sandboxing’), then outsourcing of these functions can be considered.

- Critical incident response support

In the event of a serious incident, the SOC may lack the resources to perform a correct response, in which case a contract with a service provider who can provide assistance will be very helpful. This need can arise even for a serious, mature SOC, who would also be better off contracting in advance to avoid wasting time negotiating contracts during an incident.

- Penetration testing and Red Teaming (analysing security by emulating the actions of attackers)

These functions can be outsourced on a one-time or permanent basis. The reasons for outsourcing these services may be legal requirements, the need for external control, independent assessment of security. The opinion of an external party may indicate to the company's management those vulnerabilities or problems that cannot be demonstrated otherwise.

5.6 The use of turnkey tools as a form of outsourcing

It is currently possible to ‘build’ a SOC toolkit entirely on Open Source or existing stand-alone products, but the costs of support, configuration, customisation may reduce the cost-saving benefits; it will also be necessary to hire and retain appropriate professionals. But purchasing dedicated security technologies may require recurring support costs, licence renewals and, in the case of cloud-based solutions, monthly subscription renewals. The purchase of such solutions will still require a competent engineer to manage the implemented solution.

5.7 Full Outsourcing Model

In case of small infrastructure (less than 10000 devices/users) it may not be reasonable to maintain your own SOC, but monitoring and response to IS incidents is still required - in this case the company can turn to MSSP (Managed Security Service Provider) to fully outsource all SOC functions. The criteria for selecting an MSS provider can be:

- Business model and pricing policy;

- What technologies will be used;

- How the MSS provider will understand what exactly it protects (assets, infrastructure, customer's business processes);

- How the interaction between the MSS provider and the customer will be structured (e.g., in the form of regular reporting);

- Under what conditions and how incidents will be escalated to the customer level outside of regular communications;

- SLA response metrics;

- Workload levels of MSSP analysts;

- Which legal regulations the MSS provider can ensure compliance with;

- How MSS providers train, retain, support their staff, whether they have high staff turnover;

- How information received from customers is handled and protected; how the tools used and cloud providers are aligned.

6. The need for a 24/7 SOC

The feasibility of a 24/7 SOC should be assessed taking into account that a cyber attack can occur at any time of the day or night, as well as taking into account the daily activity of the company's business processes and the capabilities of the SOC. To make a decision about 24/7 SOC operation, the questions should be answered:

- What is the likelihood of attacker activity outside of standard business hours?

- What is the size of the company, are its resources used outside of standard business hours, do employees have 24/7 access to company resources?

- Does the company have critical 24/7 business processes that depend on IT infrastructure?

- Have cyber incidents been identified that could have been prevented if the SOC had been operating around the clock?

- If a cyberattack is spotted by a SOC analyst outside of standard business hours, can resources be quickly mobilised to respond before the next business day?

- What is the staffing level of the SOC, and are there opportunities to expand the SOC team to implement 24/7 operations?

- Is it possible to get into the company's office outside of standard business hours, can an exception be made for the SOC?

- Would a SOC that does not operate 24/7 be considered a full SOC due to certain beliefs or organisational requirements?

- Is a delay in processing accumulated IS events that occurred outside of normal business hours (especially on Monday mornings, in the case of non-24-hour operations) acceptable?

If the SOC does not have the ability to work 24/7, hybrid options can be considered, for example, when only part of the SOC team works 24/7 (L1 operators), when the SOC works 12/5 (covering the most active hours of the company), when a limited number of SOC employees are on duty at weekends, when the SOC has several geographically distributed locations and can distribute the workload to them taking into account the time difference (Follow the Sun model), you can also consider the option of handovers.

If the decision is made to have a 24/7 SOC, it should be considered that there should be at least two SOC workers on duty at all times, each 24/7 position is equivalent to about five FTEs (Full-Time Equivalent) including holidays and sick leave, and analysts on night shifts may feel under-valued and invisible to the rest of the team (so it is recommended to rotate night and day shifts).

7. Choosing a location for the SOC centre

The following recommendations from the authors of the publication should be considered when selecting a physical location for the SOC:

- The SOC centre should be provided with a physical location and infrastructure to operate (premises, server rooms, SCS, network connectivity to company network segments and internet): premises within the company office or data centre may be best suited for this purpose;

- It is necessary to ensure information exchange and coordination of actions between SOC units;

- Responsibilities between the SOC and the company's IT/IS departments should be delineated; the physical presence of the SOC in the company's office will help to smooth out any friction;

- SOC staff and managers should communicate closely with company management and company departments;

- SOC analysts should provide information about the company's business processes and the context of business operations to better identify and respond to cyber threats; The physical presence of analysts in the company's office will help to interact more closely with company employees and perform physical actions on IT infrastructure elements as part of the response;

- SOC should not focus only on the office/division of the company where the SOC team members are physically located; attention should be paid to issues in other locations and divisions to maintain control of the monitoring and response function there;

- The work schedule of the majority of SOC employees should be synchronised with that of the company;

- A geographically distributed SOC structure for Continuity of Operations (COOP) is recommended; SOC centre infrastructure and operations should be incorporated into the business continuity and recovery processes.